You may find it easier to use the pillow library to load the image, convert it to black+white if necessary, and then access the raw data. It's already a dependency of quicktill (transitively via reportlab) so it's guaranteed to be available on till installations.

You may find it easier to use the pillow library to load the image, convert it to black+white if necessary, and then access the raw data. It's already a dependency of quicktill (transitively via reportlab) so it's guaranteed to be available on till installations.

Ach, I knew I should've checked more thorougly, or remembered that from dabbling with reportlab!

Would you prefer that approach, and if so, any thoughts on whether storing the logo in the DB makes sense, or is a filename reference OK? (it was finding the contents of a .css file in the config table that made me figure that DB-loading the contents might make sense)

I think storing the data as a config option in the database makes perfect sense. A shame it has to be base64 encoded, but that's on me for not having a binary config type! Something to note for the future.

I think storing the data as a config option in the database makes perfect sense. A shame it has to be base64 encoded, but that's on me for not having a binary config type! Something to note for the future.

No problem - yep, the base64 encoding is something of a tradeoff. I'll leave the config/storage as-is for now.

Ok, getting there.. the centre-alignment (or lack of) for the logo is wonky, though:

It prints!

Not sure why it's only showing half the image. The TM-T20 has 576 dots per line so I'd expect a 512×512 image to fit.

Ok, that's progress, of a sort :)

Is the black printed region near the left of your photo (outside of the circle) visible when viewing the input image?

A mini todo-list of issues:

• Determine cause of image overflow in horizontal direction.
• Avoid introduction of empty horizontal whitespace between printed lines.
• Retain original image dimension proportions/ratio on printout.
• Consider switching from P4 file format to P1 (a plaintext equivalent of P4, as I underand it; doing that could allow us to drop the base64 encoding/decoding)
• Ensure sufficient spacing between end-of-image and first line of receipt text (site name).

I think points 1 and 3 are to do with the print mode — you're using mode 0, for "8-dot single-density", which makes the printer double each pixel horizontally and triple it vertically. Mode 33, "24-dot double-density" should give more sensible results, but you'll need to work in groups of 24 rows instead of 8.

My image does have black outside the circle — that must be the default background for convert. The input to convert was a PNG with transparency.

Perhaps the stripes would disappear if we issue a single escpos.ep_bitimage_dd_v24 command that contains the correct width_info, but is followed by the payload of the entire image?

I don't think so — how would it know where the image stops? I expect we would get one valid row and then the remainder of the image data would be interpreted as text.

I can't take the more-itertools dependency at the moment. It isn't in Ubuntu 22.04 (it only has version 8.10.0) and the till needs to be able to run on Ubuntu 22.04 with system packages only.

Ubuntu 22.04 has python3-imagesize version 1.3.0 but that appears to work ok in this instance.

This may seem silly, but I'm going to rewrite that function from scratch. I haven't looked at the code for it (you'll have to take my word for that), but it's MIT-licensed whereas this is GPL -- it'd be fine to incorporate it with the appropriate inclusion of the license text, making it clear that it's vendored, etc, but I think it'll be simpler here for me to re-implement it (perhaps famous last words).

That sounds sensible. You might want to implement something that always returns the requested number of items in the batch, padding if necessary, because it could make dealing with images that aren't a multiple of 24 pixels high a bit simpler.

I forget what time of day this part of my EMF 2022 experience was:

(something slightly off about my reimplementation of _chunked at the moment..)

Ok, that's the batching/chunking code reimplemented, and seems to be working well here. The problem above was due to a missing if condition after the loop.

If I turn the print speed right down in the printer configuration, it prints without stripes:

The current version has a decent space between the bottom of the image and the site name, too.

Excellent, that looks much better. How much time does that take to print?

Sounds good. I also wonder whether an outlined version of the image might be preferable energy-wise (even if it doesn't affect the output speed).

FWIW: On a separate branch, I've pushed a commit https://github.com/jayaddison/quicktill/commit/af596773b44973b5d10e17829ea1890e8ed666d6 that migrates from P4 PBM (binary) to use P1 PBM (text) format instead; it's slightly simpler, although I don't know whether it's worthwhile. Adding the -compress none option to convert outputs that format instead.

Followup: I just pushed a commit that removes the imagesize dependency and uses Pillow to load the image instead.

This allows the image to be anything understood by the Pillow library. For example, here's what it prints when I use a huge transparent PNG from https://www.miltonbrewery.co.uk/media/pumpclips/minotaur.png :

Brilliant! Nice to have learned some ESC/P along the way here. Cheers :)